…556)

* fix(cli): stop update and restore materializing marketplace plugins

claude, codex and copilot set translationMode "marketplace", so
resolveTranslator hands them ModeAMarketplaceTranslator, whose contract is
to register a plugin reference and write nothing: its addPlugin records an
empty files set.

Update and restore did not honour that. Both narrowed the resolved
translator with `instanceof BuiltTreeMaterializationTranslator` and, for
anything else, fell through to a raw materializing path. So a plugin that
install deliberately left unmaterialized got its files written to disk and
recorded in the manifest the first time the user ran update or restore,
leaving it both natively registered and materialized.

Update's `isLocalMarketplace` guard looked like it covered this but did not:
a github-hosted marketplace resolves plugin sources to kind "git-subdir",
never "local", so the guard never fired for the case that matters. Restore
had no guard at all.

Both now dispatch on what resolvePluginTranslator returns for the tool
rather than on the translator's concrete class, so a tool's translation mode
decides the behaviour in one place. materializeViaBuiltTree widens to
materializeViaTranslator, taking the PluginTranslator interface, and both
call sites share it rather than repeating the logic.

Install was already correct and is unchanged.

cursor and opencode cannot reach this path: installScope "user" and
translationMode "flat" are matched by earlier branches in resolveTranslator,
so they only ever get BuiltTreeMaterializationTranslator or null. A flat
mode regression test covers it.

2150/2150 pass (2146 plus 4), tsc clean, golden baseline unchanged.

The new tests were verified against the pre-fix code: 3 of 4 fail there with
the predicted symptom, the flat-mode guard passes in both states.

Known gap, not fixed here: a user who already ran update or restore has
stray files on disk. Update self-heals when a newer version exists, because
it deletes the old manifest files first, but it never runs when no version
bump is available, and restore has no delete step at all so it leaves the
files orphaned once the manifest entry goes empty. Adding a symmetric delete
to restore would fix it and would also delete files on disk, so it needs a
decision rather than a silent implementation.

* fix(cli): clear plugin files a marketplace tool should never have had

Users who ran update or restore before the previous commit have stray
materialized files for marketplace-mode plugins. Update self-heals, because
it deletes the old manifest files before rebuilding, but only when a newer
version exists upstream: on the latest version it returns early and never
clears them. Restore had no delete step at all, so once the manifest entry
went empty those files were orphaned and untracked.

Restore now clears them, which makes it the reliable path for a plugin
already on the latest version.

The delete is bounded three ways. It runs only when the resolved translator
reports mode "marketplace", which only ModeAMarketplaceTranslator does; both
materializing translators report "flat", so built-tree and flat installs
cannot reach it. It iterates the plugin's own manifest keys rather than
scanning a directory, so it cannot touch a file the plugin never wrote. And
it joins those keys to the plugin base dir from resolvePluginBaseDir rather
than assuming the project root.

A file placed inside the same plugin directory but absent from the manifest
survives untouched, with a test asserting exactly that. An empty manifest
entry makes the whole thing a no-op.

deleteOldFiles moves from a private method on PluginUpdateUseCase to a
shared helper in plugin-helpers.ts, used by both. Update's call stays
unconditional: it also clears files dropped between versions on the
built-tree and translate paths, so it is not the same concern as this
cleanup.

2152/2152 pass (2150 plus 2), tsc clean, golden baseline unchanged.

Mutation-tested by forcing the guard false: both new tests fail with
"expected 'stray content' to be undefined".

…556)

* fix(cli): stop update and restore materializing marketplace plugins

claude, codex and copilot set translationMode "marketplace", so
resolveTranslator hands them ModeAMarketplaceTranslator, whose contract is
to register a plugin reference and write nothing: its addPlugin records an
empty files set.

Update and restore did not honour that. Both narrowed the resolved
translator with `instanceof BuiltTreeMaterializationTranslator` and, for
anything else, fell through to a raw materializing path. So a plugin that
install deliberately left unmaterialized got its files written to disk and
recorded in the manifest the first time the user ran update or restore,
leaving it both natively registered and materialized.

Update's `isLocalMarketplace` guard looked like it covered this but did not:
a github-hosted marketplace resolves plugin sources to kind "git-subdir",
never "local", so the guard never fired for the case that matters. Restore
had no guard at all.

Both now dispatch on what resolvePluginTranslator returns for the tool
rather than on the translator's concrete class, so a tool's translation mode
decides the behaviour in one place. materializeViaBuiltTree widens to
materializeViaTranslator, taking the PluginTranslator interface, and both
call sites share it rather than repeating the logic.

Install was already correct and is unchanged.

cursor and opencode cannot reach this path: installScope "user" and
translationMode "flat" are matched by earlier branches in resolveTranslator,
so they only ever get BuiltTreeMaterializationTranslator or null. A flat
mode regression test covers it.

2150/2150 pass (2146 plus 4), tsc clean, golden baseline unchanged.

The new tests were verified against the pre-fix code: 3 of 4 fail there with
the predicted symptom, the flat-mode guard passes in both states.

Known gap, not fixed here: a user who already ran update or restore has
stray files on disk. Update self-heals when a newer version exists, because
it deletes the old manifest files first, but it never runs when no version
bump is available, and restore has no delete step at all so it leaves the
files orphaned once the manifest entry goes empty. Adding a symmetric delete
to restore would fix it and would also delete files on disk, so it needs a
decision rather than a silent implementation.

* fix(cli): clear plugin files a marketplace tool should never have had

Users who ran update or restore before the previous commit have stray
materialized files for marketplace-mode plugins. Update self-heals, because
it deletes the old manifest files before rebuilding, but only when a newer
version exists upstream: on the latest version it returns early and never
clears them. Restore had no delete step at all, so once the manifest entry
went empty those files were orphaned and untracked.

Restore now clears them, which makes it the reliable path for a plugin
already on the latest version.

The delete is bounded three ways. It runs only when the resolved translator
reports mode "marketplace", which only ModeAMarketplaceTranslator does; both
materializing translators report "flat", so built-tree and flat installs
cannot reach it. It iterates the plugin's own manifest keys rather than
scanning a directory, so it cannot touch a file the plugin never wrote. And
it joins those keys to the plugin base dir from resolvePluginBaseDir rather
than assuming the project root.

A file placed inside the same plugin directory but absent from the manifest
survives untouched, with a test asserting exactly that. An empty manifest
entry makes the whole thing a no-op.

deleteOldFiles moves from a private method on PluginUpdateUseCase to a
shared helper in plugin-helpers.ts, used by both. Update's call stays
unconditional: it also clears files dropped between versions on the
built-tree and translate paths, so it is not the same concern as this
cleanup.

2152/2152 pass (2150 plus 2), tsc clean, golden baseline unchanged.

Mutation-tested by forcing the guard false: both new tests fail with
"expected 'stray content' to be undefined".